326732 - disabled submit inputs have text selection (I-beam) cursor

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[dolphinling]

Disabled submit inputs have the text cursor instead of an arrow like non-disabled ones. Testcase in URL. 

Does not occur on FF1.5 Windows, so I'm assuming it's a regression, though it could conceivably be Linux only...

Comment 1

[Martijn Wargers (dead)]

No, I can see it too on windows, with current trunk build.
Might be useful to know when this regressed.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Regression between 1.9a1_2006012517 and 1.9a1_2006012609.

Comment 3

[Martijn Wargers (dead)]

Ah, thanks Ria. So I guess bug 317375 is responsible for the change in behavior.
But it seems to me this behavior is a logical consequence, considering the cursor: inherit; rules in forms.css for disabled inputs.
This was added with bug 260399. Boris you insisted on changing it from "default" in the CSS to "inherit". Are you sure it shouldn't be "default"?

Comment 4

[Boris Zbarsky [:bzbarsky]]

> But it seems to me this behavior is a logical consequence, considering the
> cursor: inherit; rules in forms.css for disabled inputs.

Why?  It seems to me the behavior is a logical consequence of roc changing (well, actually removing) the hit-testing going on in nsHTMLButtonControlFrame in bug 317375.

> Are you sure it shouldn't be "default"?

Yes, since "cursor" is inherited.  Consider:

  <div style="cursor: pointer"><input disabled></div>

Imo the cursor should be a pointer (which is what it would be if input were not special), not an arrow (which is what it would be if we use "default").

In any case, the inherit is not the problem.  The problem that the text frame is ending up as the target when we're doing UpdateCursor is.  That didn't use to be the case.

That said, the old hit testing in nsHTMLButtonControlFrame is a little odd for <button>.  Perhaps nsGfxButtonControlFrame should override some of this stuff?  After all, an <a> inside a <button> should be clickable, and I'm not sure it was before...

Comment 5

[Martijn Wargers (dead)]

Yeah, you're right.

I guess this bug and bug 326827 could be related to each other.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yeah, indeed.  The same code's involved.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Should be fixed by the patch in bug 326827.